Well, not the best choice because trace depends on it too :')

IMO all relative paths should always be printed relative to . because that's the reference point for users...

But for std and lib it's not relative to . , so it's not very consistant. At the same time lib are not user's files, so it makes sens too.
trace use this too and it did not surprised me, so maybe that's ok after all x)

I'm a bit salty that I open an issue about HL's relative path printing being inferior, and then you open a PR to make other targets behave like HL. x)

Relative file paths should be relative to the current working directory because that's the reference point for both users and the IDEs they use. Trimming the relative src or whatever directory makes the file paths ambiguous and impossible to find without context. A printout of src/File.hx can be understood as ./src/File.hx which is nice and easy to locate, whereas what we have with this change is essentially ./File.hx which doesn't exist.

I really don't understand why anyone would consider this better.

I took some time to hesitate between make HL behave like others targets / make others target behave like HL. I thought that relative file path is always relative to class paths (the case of std and lib path), that's why at some point I was trying to "fix" it.

I apologize for the confusion :/

This PR now only modify HL.

Additional mini bugs observed:

• relative_path does not work the same way if we use -cp <absolute/path/to>/src (trim src) instead of -cp src (not trim src).
• Path.get_full_path on windows do not remove the trailing /

I feel like we wanted to look into something else here but I'm happy to merge this regardless.